BTeV Level 1 Vertex Trigger 



Michael H.L.S. Wang 
For the BTeV Collaboration 

Fermi National Accelerator Laboratory, Batavia, IL 60510, USA 
Abstract 

BTeV is a £>-physics experiment that expects to begin collecting data at the CO 
interaction region of the Fermilab Tevatron in the year 2006. Its primary goal is 
to achieve unprecedented levels of sensitivity in the study of CP violation, mixing, 
and rare decays in b and c quark systems. In order to realize this, it will employ 
a state-of-the-art first-level vertex trigger (Level 1) that will look at every beam 
crossing to identify detached secondary vertices that provide evidence for heavy 
quark decays. This talk will briefly describe the BTeV detector and trigger, focus 
on the software and hardware aspects of the Level 1 vertex trigger, and describe 
work currently being done in these areas. 



1 BTeV Detector 



The BTeV detector is a collider detector with two back-to-back forward spec- 
trometers (1.5 < \rj\ < 4.5) having sub-detectors in each arm for charged 
particle tracking, EM calorimetry, RICH particle ID and muon detection [1]. 
At the core of the detector is a 30 station Si-pixel inner tracker spanning ^120 
cm centered at the IR (a z = 30 cm) and immersed in a 1.6 Tesla dipole field. 
There are over 20 x 10 6 active rectangular pixels measuring 50 x 400 /im 2 . 
Each pixel station has two planes, one with narrow pixel dimension oriented 
in the x-direction and the other with narrow dimension in the y-direction. 



2 BTeV Trigger 



BTeV will operate at a luminosity of 2 x 10 32 cm -2 s _1 corresponding to (2) 
interactions per beam crossing at a crossing rate of 7.6 MHz. Average event 
sizes will be ~200 KB after zero-suppression of data is performed on-the-fly 
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Fig. 1. BTeV Three-Level Trigger Architecture 

by front-end detector electronics. Since every beam crossing will be processed, 
this translates to an extremely high data rate of ^1.5 TB/sec! 



To handle this high rate, BTeV will employ a three-level hierarchical trigger 
architecture [2] (see Fig. 1). Sparsified data from all detector components will 
be sent via optical links to Level 1 (LI) buffers. Data from the pixel and muon 
detectors will also be sent to the LI trigger processor. Trigger decisions from 
the LI muon and vertex trigger will be passed on to the Global Level 1 (GL1) 
trigger manager whose decisions will be stored as a list of accepted crossing 
numbers by the Information Transfer Control Hardware (ITCH). LI will reject 
99% of all incoming events reducing the data rate by a factor of ~100 to ~15 
GB/sec. 

Levels 2 & 3 (L2/3) will be implemented with a cluster of commodity CPU 
nodes. A request from an idle L2 node will be sent to the ITCH which will 
respond by assigning an accepted crossing number to that node. This node will 
then request a subset of the data (pixels+forward tracking) for that crossing 
from the LI buffer managers. A switch will combine pixel data with forward 
tracking data for the same crossing and route them to the buffer of an L2 node 
allowing a more refined analysis that will further reduce the data rate by a 
factor of ^10. 

If that passes the L2 selection criteria, the same processing node will then 
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enter the L3 phase and request data from the rest of the sub-detectors be 
transferred from the LI to the L3 buffers (L2/3 buffers will simply be the 
RAM attached to the processing node). Using complete information from the 
detector, L3 will reduce the crossing rate by an additional factor of ^2. Since 
L3 will also be able to further compress the data in the accepted crossings by 
a factor of ~4, the expected data rate out of L3 is ^200 MB/sec. 



3 Level 1 Vertex Trigger Algorithm 

The first phase of the LI vertex trigger algorithm is the track finding phase 
[3] which starts by finding the beginning and ending segments of tracks in two 
separate regions of the pixel planes, an inner region close to the beam axis 
and an outer region close to the edge of the pixel planes. The search for the 
beginning and ending segments of tracks is restricted to these inner and outer 
regions respectively. Segments are found using hit clusters from three adjacent 
pixel stations in the defined regions. Inner segments are required to point back 
to the beam axis while outer segments are required to project outside pixel 
plane boundaries. Once these segments are found, they are then matched to 
form complete tracks in the segment matching stage. 

After complete tracks are found, the vertexing phase [4,5] determines the mo- 
mentum of each track and calculates its transverse distance from the beam 
axis. Primary vertices are found by looping through all tracks with transverse 
momentum p T < 1.2 GeV/c that appear to originate close to the beamline. 
Remaining tracks are then tested for their detachment from the primary ver- 
tices found. A LI vertex trigger is generated if there are at least 2 tracks in 
the same arm of the BTeV detector satisfying the following criteria: ip\ > 0.25 
(GeV/c) 2 , b > 6a, and b < 2mm where b is the impact parameter. 

Our studies indicate that the LI vertex trigger is able to reject 99% of all 
minimum-bias events while accepting ^60-70% of the £>-events that would 
survive our offline analysis cuts. 



4 Level 1 Vertex Trigger Hardware 

A block diagram of the LI vertex trigger is shown in Fig. 2. Data from all 30 
stations of the pixel detector are sent to FPGA based pixel processors that 
group individual pixel hits into clusters. Hit clusters from three neighboring 
pixel stations are routed to FPGA based hardware that find beginning and 
ending segments of tracks in the track finding phase. 



3 



Fig. 2. BTeV Level-1 vertex trigger. 

Segments found in this stage are sorted by a switch according to crossing 
number and routed to a DSP in the track/ vertex farm. This DSP performs 
the segment matching step of the track finding phase and the entire vertex 
finding phase. Based on initial studies done for the BTeV proposal [1], we 
estimate the average processing time for the combined segment matching plus 
vertex finding phase to take -330 fis on a single 167 MHz TI TMS320C6711 
floating point DSP. Since the time between beam crossings is 132ns, this will 
require a total of —2,500 DSP in the track/vertex farm in order to examine 
every beam crossing. 



5 Work in Progress 

Since hand-optimized assembly code can be difficult to maintain and debug, 
we are working on an optimized C version of the LI segment matching and 
vertexing code. A version is currently running on a C6711 DSK board in which 
we have replaced costly function calls with intrinsics that map directly to 
built-in DSP instructions and completely rewritten major sections of the code. 
Preliminary results indicate that this optimized C version is only a factor of 
^4-5 slower than the hand-optimized assembly version used for initial timing 
estimates. While we expect substantial gains in DSP chip performance in the 
next few years, we will continue to explore ways to improve code performance, 
resorting to hand-optimized assembly programming only when necessary. 
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We are developing a prototype board for the segment matching and vertex- 
ing portion of the LI trigger with four DSP's on mezzanine cards. Onboard 
FPGA input and output buffers will have an LVDS interface to a host com- 
puter through which simulated data can be sent. Buffer managers in the FPGA 
will channel data to and from each DSP via DMA transfers. Trigger results 
from each processor will be sent through an FPGA interface to an on-board 
/i-cont roller that will format the results and forward them to GL1 through 
ArcNet. A host computer serving as a pixel trigger supervisor monitor will be 
connected to a second on-board /x-controller through ArcNet, allowing com- 
mands to be sent to the board, initialization of the DSP's, and providing 
hardware monitoring and fault detection. JTAG ports will also be available 
for real-time debugging and initial start-up of the prototype. 

We are also implementing the LI segment finding algorithm in FPGA's and 
doing simulations and queuing studies of the algorithm with MATLAB. 

As a final note BTeV will greatly benefit from a newly approved NSF funded 
project called RTES (Real Time Embedded Systems) [6] which will develop a 
semi-autonomous, self-monitoring, fault-tolerant and adaptive framework for 
addressing issues facing complex computing architectures like that of BTeV. 



6 Conclusion 

We have designed a Level 1 vertex trigger that will address the demanding 
requirements of BTeV. We are currently working on optimizing a high-level 
version of the vertex trigger algorithm and developing a prototype board for 
investigating various aspects of the LI vertex trigger hardware. 
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